Current operating systems typically include a graphical drawing interface layer that is accessed by applications in order to render drawings on a display, such as a monitor. The graphical drawing interface layer provides applications an application programming interface (API) for drawings and converts drawing requests by such applications into a set of drawing commands that it then provides to a video adapter driver. The video adapter driver, in turn, receives the drawing commands, translates them into video adapter specific drawing primitives and forwards them to a video adapter (e.g., graphics card, integrated video chipset, etc.). The video adapter receives the drawing primitives and immediately processes them, or alternatively, stores them in a First In First Out (FIFO) queue for sequential execution, to update a framebuffer in the video adapter that is used to generate and transmit a video signal to a coupled external display. One example of such a graphical drawing interface layer is the Graphical Device Interface (GDI) of the Microsoft® Windows operating system (OS), which is implemented as a number of user-level and kernel-level dynamically linked libraries accessible through the Windows OS.
With the rise of technologies such as server based computing (SBC) and virtual desktop infrastructure (VDI), organizations are able to replace traditional personal computers (PCs) with instances of desktops that are hosted on remote desktop servers (or virtual machines running thereon) in a data center. A thin client application installed on a user's terminal connects to a remote desktop server that transmits a graphical user interface of an operating system session for rendering on the display of the user's terminal. One example of such a remote desktop server system is Virtual Network Computing (VNC) which utilizes the Remote Framebuffer (RFB) protocol to transmit framebuffers (which contain the values for every pixel to be displayed on a screen) from the remote desktop server to the client. In order to reduce the amount of display data relating to the graphical user interface that is transmitted to the thin client application, the remote desktop server may retain a second copy of the framebuffer that reflects a prior state of the framebuffer. This second copy enables the remote desktop server to compare a prior state and current state of the framebuffer in order to identify display data differences to encode (to reduce network transmission bandwidth) and subsequently transmit onto the network to the thin client application.
However, transmitting the display data differences onto the network to the thin client application can deteriorate performance of both the remote desktop server and the thin client application due to the computing overhead needed to encode the display data differences at the remote desktop server and subsequently decode them at the thin client application. As a general example, to continually transmit data from an entire framebuffer that supports a resolution of 1920×1200 and color depth of 24 bits per pixel onto the network at a rate of 60 times per second would require transmission of over 3.09 gigabits per second. Even assuming that display data differences (rather than an entire framebuffer) can be identified and further compressed through encoding techniques prior to transmission, significant network bandwidth may still be required.